home *** CD-ROM | disk | FTP | other *** search
/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr48 / 386p_200.zip / HOWTO.TXT < prev    next >
Text File  |  1995-01-14  |  11KB  |  213 lines
  1. Here comes the "how to do..." list of the most common things
  2. useful to know if you wanna make games.
  3. They are lots of silly things, but they make the differece between a good game
  4. and a good-idea-but-badly-implemented game.
  5.  
  6. How to ...
  7.  
  8. ------------------------------------------------------------------------------
  9. * ... choose the "perfect" animation frequency/frame rate
  10.  
  11. Humans have a "feedback" (the time it takes to react) frequency of about 10Hz
  12. (nothing strange, it is close to the frequency of brain waves).
  13. But the visual system is a lot complex, so even if the "frame rate"
  14. of a common eye is about 10..15 Hz
  15. the visual system can perceive "flashes" up to 50Hz
  16. (you don't see the "flash" but you perceive the image is not rock solid)
  17. (that's why televisions use long persistance phosphors to "smooth"
  18.  the electronic beam flashing the dots).
  19.  
  20. Do you feel worried? Worry not! This has nothing to do with us.
  21.  
  22. If the screen image is "steady"
  23. (read: the monitor has 60Hz refresh frequency, better if 72hz or more)
  24. your eye performs interpolarion of frames with  about a 10hz frequency
  25. (usually 12Hz) and gets a "steady" image.
  26. Just going at 12 FPS (Frames Per Second) produces smoothly ANIMATED sequences
  27. (by the way 12 FPS was the frame rate of animations in Disney's cartoons).
  28. Notice i said ANIMATED SEQUENCES, NOT MOTION.
  29. At 12 FPS a "static" animation (i.e a face changing from angry to smiling)
  30. is good enough to not be "jumpy" (but looks a little "slow").
  31. But if it is a sprite in motion (i.e. a walking man)
  32. you need a higher frame rate.
  33. Why? Because our motion detection system works at about 10..12Hz, you need
  34. twice the "feedback" frequency to fool it.
  35. So "change sprite image" 12 times in a second, but move 'em
  36. at least 24 times in a second.
  37.  
  38. Usually on arcade games 12 FPS are good enough
  39. (the feedback time does not need to be realistic).
  40. BUT for flight simulators or other things like that, 24 FPS are the minimum
  41. to get realistic animation and 50 FPS are the minimum for "total feedback"
  42. (when you "feel" that eye and hand motion are coordinated)
  43. So always include some options to speed up animation with a little
  44. and/or a big loss of detail.
  45.  
  46. Well, NOW you know the lower "good animation" limits:
  47.  
  48. "Image update" can go as low as 12 FPS and look very realistic
  49. depending on what you do, you can go even lower (i.e. combining motion
  50. with image changes) and still look realistic.
  51.  
  52. "Image motion" must be at least 20..24 FPS to look realistic on simulators
  53. and 50 FPS to give "perfect" feedback to commands.
  54.  
  55. NOW COMES THE HIGHER LIMITS:
  56.  
  57. Moving things too fast makes just "flashes and streakes", use a timer
  58. to get always the same motion speed indipendently of the frame rate
  59. ( notice the 386TIMER module , you don't need a timer interrupt for everything
  60.   just calculate the time elapsed and then
  61.   calculate the "motion to show" on next frame).
  62.  
  63. -------------------------------------------------------------------------------
  64. * ... perform smooth scrolling with no hardware support
  65.  
  66. Quite easy, if you want to have a screen (_DispX,_DispY) wide
  67. and want to perform animations on a virtual screen (_VirtX,_VirtY) wide
  68. simply set a screen buffer (_ScrX,_ScrY) wide
  69. where _ScrX = _DispX + _WidestSpriteX
  70. and   _ScrY = _DispY + _TallestSpriteY +1
  71.  
  72. Then set the "display start" (_VDispX,_VDispY)
  73. at (_WidestSpriteX,_TallestStriteY) to get "out of screen" borders
  74. using the "row wrap" to simulate two lateral borders even if there is only one.
  75.  
  76. Then keep a pair of variables to memorize what is the actual position
  77. corrispondent to screen buffer coordinates (0,0).
  78.  
  79. At every frame regenerate the "visible image" on the screen buffer,
  80. then blit it to the actual screen.
  81.  
  82. This was the hard part, now you have to decide when to scroll and how much.
  83.  
  84. Usually you want to scroll to follow the "player's character" on screen
  85. but you have to remember to sincronize scrolling with animation
  86. or you'll get "jumpy" scroll, this depends on how much action there is in the
  87. game and where the plyer's eye look at.
  88.  
  89. Another thing to keep in mind how to avoid those strange "streaks" you see
  90. if a sprite moves too fast, they are the result of interpolation between
  91. the current image and the previous, to reduce this effect use sprites
  92. with a "dark" border (better if black), or don't scroll/move more than
  93. 1..2 pixels at a time if you cannot sinchronize "scrolling steps"
  94. with the frame rate.
  95.  
  96. ------------------------------------------------------------------------------
  97. *  ... play multiple sounds with a single DAC
  98.  
  99. Usually, with a DMA channel and an IRQ line you can tell the sound board
  100. "take this chunk of memory and send it to the DAC"
  101. without having to send it one byte at a time.
  102. [ you program a DMA transfert, then when the transfert ends, the sound board
  103.   raises and IRQ signal, so if after the first "feed" you place the
  104.   "dma restart for next block of data" on the ISR (Interrupt Service Routine)
  105.   serving that IRQ, you get continous sound with minimal cpu overhead]
  106.  
  107. But if you want MULTIPLE VOICES and you have a single DAC
  108. you have to perform SOFTWARE SOUND MIXING, you take the various sound samples
  109. you want to play and add them together (to mix the signals)
  110. and then send the result to the sound output DAC.
  111.  
  112. The easiest approach is disabling DMA, chaining to a timer interrupt running
  113. at the playback frequency you want and every time the interrupt "ticks"
  114. you add the current values to send and then write the result to the DAC.
  115. This method uses the cpu a lot (and the more your cpu spends time
  116. executing irq routines, the less time it will work on your main program)
  117. going beyound a 8Khz playback frequency can cause serious processing problems.
  118. Forget to make it work under Windows (too much irq response overhead)
  119. and forget to have CD frequency playback (Sheesh! An ISR for timer interrupts
  120. ticking at 44Khz eats nearly all cpu time on a plain 486 !!!).
  121.  
  122. There is a better method, you still use a DMA channel and an IRQ line
  123. to send the data to the DAC, but every time the current sound data
  124. has been sent, you call a "software mixing" routine to mix
  125. a block of N samples adding together the next N samples of the various
  126. voices you want to play.
  127. This way you reduce a lot the interrupt overhead
  128. (i.e. if with a "timer interrupt mixing" at 8Khz you had 8000 irqs in a second
  129.       using "block mixing" with 100 samples per block you only have 80 irqs
  130.       in a second).
  131. Of course, this has problems too, you have to "compose the block of data"
  132. BEFORE the IRQ requests another block (or you'll get "pauses")
  133. That is, the block you compose "now" will have to be sent
  134. AFTER the current block is played.
  135. The mixing process works at a frequency that depends on how many samples
  136. you put in a block of sound data and depends on what is the playback frequency.
  137. For example: With a playback frequency of 8000 Hertz
  138.              and mixing sound in blocks of 100 samples each
  139.              the mixing routines gets called 80 times in a second (80 Hertz)
  140.              [ mix_frequency = playback_frequency/block_size_in_samples ]
  141.  
  142. The less interrupts happens the better so, maybe you want a lower
  143. "mixing frequency", but you have to remember that you cannot go lower
  144. than 30Hz.
  145. The reason for this is that animation (not motion) happens at 12 FPS
  146. and you "play late the sound" (the "time fidelity" of sounds is half
  147. the mixing frequency).
  148. If you try to use lower mixing frequencies you will get "decoupled"
  149. sound and animation.
  150.  
  151. On the other side, sending big chunks of mixed sound data
  152. takes processing power.
  153. IF you process too big chunks YOU MAY GET "stop-go animations".
  154. IF you process too little chunks with an high playback frequency
  155. YOU MAY GET lots of cpu overhead caused by too many interrupts.
  156. So include an option to change the playback frequency
  157. and/or the number of voices you mix on the flight.
  158.  
  159. -------------------------------------------------------------------------------
  160. * ... experience the effect of a Non-lethal Disabling Technology (URK!!!!)
  161.  
  162. Ever heard of the Bucha effect? When you are exposed to strong flashing lights
  163. and they flash with a frequency close to that of brain waves
  164. (brain waves are usually in the 10..20 Hz range)
  165. you get vertigo and feel quite unhealty (you feel like you are gonna puke).
  166.  
  167. So avoid to put "big flashing light" effects "blinking" at a fixed frequency.
  168.  
  169. A classic for this effect is Doom 1 level 2 (the nuclear plant)
  170. one of the secret zones simulates broken flourescent lights perfectly
  171. and gives a good example of nearly-Bucha effect on videogames.
  172. Another is Jazz Jackrabbits's Tubelectric level.
  173.  
  174. The same thing applies to sound, if you use "block mixing" remember
  175. to always put in at least a soft "background music", the low frequency hiss
  176. caused by the constant frequency of mixing you get on some sound boards
  177. is disturbing to say the least. (Yeah! block mixing can add noise
  178. to the actual sound, if the gap between the time a block finishes
  179. and the next starts playing is too wide) (the "silence" between blocks
  180. sometimes is real, but in some boards is a "fall to zero" that causes noise).
  181.  
  182. -----------------------------------------------------------------------------
  183. * ... avoid sonic booms
  184.  
  185. Remember to always include volume settings into the game
  186. because not everyone has speakers with sound volume control.
  187.  
  188. Months ago, when i had two high-wattage stereo speakers
  189. connected to the soundcard, i uploaded a game called Riptide.
  190. It had no sound volume controls
  191. after five minutes i erased it, it was too darned loud.
  192. Now i have a pair of little speakers with volume control
  193. [ 4watt speakers are good enough and you dont' have to steal the speakers
  194.   from your brother's stereo rack :) ]
  195.  
  196. Another thing to remember is to "fade sounds" ("fade in" when it starts
  197. and "fade out" when it ends)(do it preprocessing the sound data)
  198. because "brutal" changes of  DAC  output levels causes "dings!" "tings!"
  199. and other noises.
  200. Guess what happens if you mix together 4 or more sounds starting/ending
  201. at the same time.
  202.  
  203.  
  204. Thats' all....
  205.  
  206. Well, i think these are the basic advices you may need to avoid problems
  207. and reduce your "game programming" learning curve.
  208. Remember these are generic advices, with good programming skills you can
  209. "cut corners" without losing too much playability, i'm not a big time
  210. game programmer, i'm just an electronic engineering student with a strong
  211. background in assembler coding.
  212.  
  213.